Modernly, the use of PCs (personal computers), including so-called laptop and notebook computers, is increasingly common and the computers themselves are ever more powerful and complex. Hardware development continues at great rates resulting in families of PCs that share parts and partial configurations yet have evolving capabilities and legion configurations. A persistent problem is the management of needed changes and enhancements to firmwares as new versions of hardware and entirely new hardware subsystems are phased in—while simultaneously avoiding excessive duplication of effort across families of related, but different, computer products. This leads to a need for capabilities above and beyond those found in previously developed source and build management systems.
Firmware development for PCs presents substantially different problems (requiring substantially different solutions) from software development. Previously developed software development solutions either have systems programs to handle routine programming minutiae and/or comprise systems program(s) that can rely on firmware features to largely hide hardware dependencies. Different again is development for embedded firmware—that firmware typically supports only a very few hardware configurations and/or versions, as contrasted with the very many of each found in PC firmware.
Intel Corporation first defined EFI (Extensible Firmware Interface) as the programming interface exposed by firmware to O/S (operating system); former comparable firmwares were not sufficiently portable nor scalable to Intel's CPU (Central Processor Unit) IA64 (Intel Architecture for 64 bit widths) architecture. A first implementation of the EFI interface became known as Tiano, which Intel Corporation offered under license via a web site. The UEFI (Unified EFI) Forum, a trade group, secured architectural control over derivatives of EFI under a new name—UEFI, with a right to support and extend. The UEFI Forum specifies and documents the UEFI interface itself.
The PIWG (Platform Initialization Working Group) of the UEFI Forum provides a common internal framework for Silicon and platform drivers, so that a common understanding of the roles and methods used by Silicon and platform drivers is developed by implementers of UEFI firmware stacks together with the providers of the Silicon and platform drivers. Silicon and platform drivers are each well-known in the PC firmware arts.
The UEFI and related standards provide richness, but fail to sufficiently address significant specific areas of concern including at least:                Quality of board bring-up user experience        Quality of BIOS (Basic Input-Output System) customization experience        Duration of system bootloading and platform initialization time        Level of reliability        Level of compatibility with Intel's Foundation Core (also known as Foundation for short and a discrete part of Tiano)        Scope for platform innovation by BIOS vendors and partners and customers thereof.        
These attributes are described in a version of SCT (SecureCore-Tiano™) System Overview document published by Phoenix® Technologies Ltd. (herein “Phoenix”). Adequately addressing all of these areas of concern requires innovation above and beyond what is described in UEFI and PIWG standards and related documents.
In restructuring the build mechanism with corresponding source programs and databases, opportunities arise to remedy shortcomings in the previously developed solution (known as EDK1). One such problem is the large amount of effort required to perform so-called customization of UEFI builds to suit the requirements of OEMs (Original Equipment Manufacturers) and others. Customization is a term of art in the UEFI build arts and refers, inter alia, to the adapting of a firmware product from a first computer design to a related or derived design. This is typically from a CRB (Customer Reference Board) produced by a SV (Silicon Vendor) and to a board laid out by the OEM and which may incorporate hardware changes that are substantial in scope, but nonetheless relatively limited in variety. This might include hardware port configuration and connect to external electronic devices. It might also include memory of differing operational modes, types, sizes, performance, operating parameters and so on as compared with that on the CRB. Input-Output routing, IRQ (interrupt request) and APIC (Advanced programmable interrupt controller) routing may be selected to suit local desires. Moreover entirely different Silicon (complex semiconductors) may apply, for example a Southbridge chip different from that on the CRB may be selected, such as for reasons of evolving availability, performance and/or cost.
In order to address these issues the structure, both build-time and run-time, of the UEFI components (typically modules) has been reworked in a novel and advantageous configuration. The improvements are as described below.
A significant advantage of embodiments of the invention over previously developed solutions is that the effort of the customization process for multiple types of chipsets (also Silicon), platforms (also product families), hardware levels (especially improved, significantly revised and novel subsystems), and firmware revision levels (especially levels of deficiency and fault remedies) is significantly reduced. And in consequence a plurality of more consistent and higher quality UEFI based distributed products emerge.